It is common for information consumers to request that dynamically generated information be rendered according to different techniques depending on the tools or devices used. Among these techniques are: direct drawing to a computer screen; printing; HTML instructions; PDF formats; Word formats, and so forth. While some existing systems (in particular, reporting systems) can perform core data calculations a single time for multiple rendering targets, no system has managed to deal with the problem of performing or sharing layout/pagination calculations across formats. For instance, each output format currently requires a separate renderer, which lays out and paginates the calculated data, and generates the desired format as illustrated in prior art drawing FIG. 8.
Referring to FIG. 8 a prior art rendering system 800 is illustrated, data 810 and report definition information 820 are processed at 830 to generate five different rendering formats for five different renderers at 840 in this example (e.g., HTML, RGDI, Image, Excel, PDF). Output from the renderers 840 is sent to various display controls 850 for subsequent display. The system 800 presents a simplified view of a prior art rendering architecture. When a client application at 850 requests one or more pages of a report in a target format, the Report Processing module 830 acts upon the Data 810 based on the instructions contained in the Report Definition 820. The resulting processed report data is provided to one of a number of rendering modules at 840, depending on which was requested by the client application at 850: HTML, RGDI (a remote drawing instructions stream), Image, Excel, PDF, and so forth.
Each renderer 840 utilizes its own pagination and layout logic to generate the target output format. The resulting file or stream is then passed to the client application at 850. In the case of a Webforms control, HTML is embedded in the generated web page which is displayed to the user in a web browser. In the case of a Winforms control, an RGDI stream is interpreted as drawing instructions to directly draw the page on the user's screen. In the case of a Print control, the image file contains all requested pages of the report and is passed to a printer. In other cases, the output file is simply downloaded to the client machine.
The current approach illustrated by the system 800 has a number of undesirable limitations. In one aspect, the system 800 lacks layout/pagination consistency across various output display formats. Since each renderer implements its own layout/pagination logic, variances in that logic inevitably arise, leading to subtly (or occasionally dramatically) different layout/pagination depending on the output type chosen. Another deficiency in the system 800 is that there is unnecessary computational load since the layout/pagination is redundantly recalculated for each requested format. Adding to the loading problem, there is redundant handshaking and controls that are passed between applications to adequately support the various formats.